Skip to content

docs(VT-REFTIER-HOST-ADDRESSABLE): VT_ADOPT_DEVICE_BYTES reaches Metal and integrated ROCm, and its numbers do not (#1502) - #1615

Closed
localai-bot wants to merge 2 commits into
mainfrom
row/VT-REFTIER-HOST-ADDRESSABLE-1502
Closed

docs(VT-REFTIER-HOST-ADDRESSABLE): VT_ADOPT_DEVICE_BYTES reaches Metal and integrated ROCm, and its numbers do not (#1502)#1615
localai-bot wants to merge 2 commits into
mainfrom
row/VT-REFTIER-HOST-ADDRESSABLE-1502

Conversation

@localai-bot

Copy link
Copy Markdown
Collaborator

docs/ENVIRONMENT.md described the lever's reach as "Vulkan today" and closed
with "No effect on CUDA/CPU/Metal, whose backends do not advertise the property".
Both halves stopped being true at cffe59b02 (#1477).

That change moved ReferenceTierEligible off the wider UnifiedMemory() onto
Backend::DeviceMemoryIsHostAddressable(), and added truthful overrides so no
backend silently lost the reference tier. MetalBackend now answers
MetalContext::unified_memory() and RocmBackend answers its unified_memory_.
The weight loader gates this lever on exactly that predicate, at both
AdoptDeviceBytesAsHost branches in qwen3_5_weights.cpp, so the lever acts on
Apple silicon and on an integrated ROCm part.

The correction is not "add two backend names". Every number in that row is GB10
through Vulkan, and nobody has measured the lever on either new arm. The row read
as if the measurement covered the reach, so it now says which backends it is
MEASURED on and which merely satisfy the predicate. CUDA and CPU are unchanged
and still inert: neither overrides the default false, which
tests/vllm/platforms/test_platform.cpp pins for GB10, and the CPU backend
reporting UnifiedMemory() == true while the narrower predicate stays false is
the whole reason the two properties are separate.

Verified against the tree rather than against the issue: the three overrides, the
two gate sites, the absent CUDA and CPU overrides, and the GB10 assertion were
each read at this head.

The measurement on Metal and on integrated ROCm stays owed. It needs an
Apple-silicon box or an integrated AMD part, which this row has not taken, so it
is recorded under ## Owed in the spec that widened the predicate rather than
left to be discovered from a document that now promises less than it did.

No checker relates a backend predicate to a prose sentence, and none can be built
cheaply, which is why this landed as a document defect rather than a red gate.

Fixes #1502

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [Claude Code]

mudler added 2 commits August 21, 2026 17:18
…l and integrated ROCm, and its numbers do not (#1502)

`docs/ENVIRONMENT.md` described the lever's reach as "Vulkan today" and closed
with "No effect on CUDA/CPU/Metal, whose backends do not advertise the property".
Both halves stopped being true at `cffe59b02` (#1477).

That change moved `ReferenceTierEligible` off the wider `UnifiedMemory()` onto
`Backend::DeviceMemoryIsHostAddressable()`, and added truthful overrides so no
backend silently lost the reference tier. `MetalBackend` now answers
`MetalContext::unified_memory()` and `RocmBackend` answers its `unified_memory_`.
The weight loader gates this lever on exactly that predicate, at both
`AdoptDeviceBytesAsHost` branches in `qwen3_5_weights.cpp`, so the lever acts on
Apple silicon and on an integrated ROCm part.

The correction is not "add two backend names". Every number in that row is GB10
through Vulkan, and nobody has measured the lever on either new arm. The row read
as if the measurement covered the reach, so it now says which backends it is
MEASURED on and which merely satisfy the predicate. CUDA and CPU are unchanged
and still inert: neither overrides the default `false`, which
`tests/vllm/platforms/test_platform.cpp` pins for GB10, and the CPU backend
reporting `UnifiedMemory() == true` while the narrower predicate stays `false` is
the whole reason the two properties are separate.

Verified against the tree rather than against the issue: the three overrides, the
two gate sites, the absent CUDA and CPU overrides, and the GB10 assertion were
each read at this head.

The measurement on Metal and on integrated ROCm stays owed. It needs an
Apple-silicon box or an integrated AMD part, which this row has not taken, so it
is recorded under `## Owed` in the spec that widened the predicate rather than
left to be discovered from a document that now promises less than it did.

No checker relates a backend predicate to a prose sentence, and none can be built
cheaply, which is why this landed as a document defect rather than a red gate.

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [Claude Code]
@localai-bot

Copy link
Copy Markdown
Collaborator Author

Superseded by the branch rebased onto current origin/main. GitHub reported this head CONFLICTING on the .agents/issue-index.md append even though the merge=union driver merges it clean locally, which is the known behaviour recorded for that file. The merge commit that fixed it carried no trailer block and check-commit-trailers rejected it, and repairing that in place would need a force-push. Reopened as a single commit on a fresh base instead. No content change.

@localai-bot
localai-bot deleted the row/VT-REFTIER-HOST-ADDRESSABLE-1502 branch August 21, 2026 17:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

docs/ENVIRONMENT.md still says Metal does not advertise host-addressable device memory, and ROCm is unlisted, since cffe59b02

2 participants